Add FLOP estimates for operator assembly - #2018

it should me possible to estimate at points too

Thanks for the comments, I added some changes around point estimates that I was working on.

See failing CI jobs - release notes need to be updated, and there's as style fix

I’ve updated the test descriptions and comments, added the required release-note entry, and applied the style fix.

For AtPoints assembly estimates, CPU backends now count the actual total number of points, while GPU backends keep the max points in element count. I've also added a regression test to cover both cases.

Thank you for the feedback.

Looking really close, just a couple more small things I noticed

Thanks for the feedback. I’ve updated the release note ordering, reused the existing point count helper, and added the missing documentation.
I believe this should now be ready for another look.

@jeremylt said:

Either todo for here or a follow-up: The max points in element gives the true FLOPs for GPU backends and grossly overestimates in CPU backends. For CPU backends, the FLOPs are per total number of points, not (max per elem) x (num elem)

Just a note that this will distort overall flop rates, even for surrounding events. One could find that switching to a GPU causes SNESSolve time to increase while SNESSolve Mflop/s also increases (because it does more useless flops).

Gordon Bell (with misguided emphasis on reporting high flop/s rates) has rewarded teams for using naive (non-tensor) kernels for spectral element simulation because the end-to-end flop/s rate is higher, even when everything is slower and the flop/s rate achieved in the element kernels are not even faster. They might as well have plopped in a DGEMM that goes completely unused.

So we (the libCEED maintainers and community) should at least be aware of the implications, though I can't think of an obvious place to document the interpretation effects of this specifically. (In principle one could distinguish flops performed from useful flops, but that gets messy and subjective, and hard to interpret hardware limits.)

Yeah, that's a good point. Same thing applies to our element block padding, and I think (but don't recall at the moment) that we similarly count flops done and not flops needed?

Yeah, lots of such examples. Meanwhile, GPU vendors count flops not performed with their "sparse" matrix primitives. (Basically, they are saying if you were to pad with zeros and then perform the naive dense operation, this is how many flops would have been done.)